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Abstract 

A new software tool, Caesy, is described. This tool 
provides a strongly typed programming environment 
for research in the development of algorithms and soft- 
ware for computer-aided control system design. A de- 
scription of the user language and its implementation 
as they currently stand are presented along with a de- 
scription of work in progress and areas of future work. 

Introduction 

Over the past few decades, control system design 
and analysis has become more and more dependent 
on computers. With the availability of more powerful 
hardware has come the demand for more performance. 
Computer-aided control system design tools such as 
Matlab have been used with some success in control 
system design since the early 1980’s. However, many 
workers in the development of software and algorithms 
for control system design have recognized that these 
tools have limits in both flexibility and efficiency. The 
forces driving the development of new tools include the 
desire to make complex system modeling, design and 
analysis easier; the need for quicker turnaround time in 
analysis and design; the desire to make use of advanced 
computer architectures to help in control system de- 
sign; the desire to adopt new methodologies in con- 
trol; and the desire to integrate design processes (e.g., 
structure, control, optics). We have developed Caesy 
(Computer-Aided Engineering SYstem) as a means to- 
ward discovering how these desires can best be satisfied. 
The first Matlab-type environment for matrix manipu- 
lation, called MATLAB, was developed by Cleve Moler 
in the late 1970’s, mostly at the University of New Mex- 
ico, with support from the National Science Founda- 
tion. Several other Matlab-based environments have 
been produced for control system design since then. 
Included in this group of control system design tools 
is Ctrl-C from Systems Control Technology, Matrix* 
from Integrated Systems, Inc. (ISI), Pro-Matlab from 
the MathWorks, Inc., Mat/C developed at Lawrence 
Livermore National Laboratory, and SFPACK devel- 
oped at the University of Waterloo. In this document 
we will collectively refer to these MATLAB-based envi- 


ronments as Matlab. A new-generation Matlab pack- 
age has been released from ISI. This package, called 
Xmath, seems to provide some features for easier use 
but does not offer all the features we feel are desirable. 
The success of Matlab as an environment for the design 
and application of algorithms for control system design 
implies that a new tool geared toward large order, com- 
plex problems should include capabilities provided by 
Matlab and attempt to maintain in some sense the “fla- 
vor” of Matlab. 

In the development of Caesy, our goal has been to 
provide a more advanced environment which can pro- 
vide the capabilities provided by these packages, but 
can also provide alternatives to better handle the prob- 
lems encountered when problems become complex or 
the system order creates computational bottlenecks. 
More discussion on the requirements driving the de- 
velopment of Caesy can be found in [1]. Our approach 
to solving the complexity problem will be to develop 
an “object-oriented” user interface (e.g., typed vari- 
ables and overloaded functions and operators). Our 
approach to the computational problems will be to take 
advantage of this interface to develop specialized soft- 
ware which can take advantage of any special structure 
in the models (e.g., symmetry, bandedness, sparseness). 

In this paper we will provide an overview of the cur- 
rent capabilities and implementation of Caesy, the work 
currently in progress, and work planned for the future. 

Current Implementation of Caesy 

In this section, we give an overview of Caesy and 
some of its features. Caesy is, in a concise description, 
a mix between Matlab and Ada. Caesy contains many 
of the constructs of Ada but adds features from Matlab 
and whatever other modifications we felt were needed 
to provide the required functionality. Ada w T as chosen 
as a primary influence because it provides many of the 
features required and has a procedural syntax familiar 
to many Matlab users. In addition, the syntax used in 
the Caesy language is close to that being encouraged 
as an IFAC and IEEE standard (see [2]). 

Tidbits 
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Caesy is an interactive shell and thus processes user 
input on a command by command basis. The prompt 
‘caesy>’ shown below implies that the input is at the 
top level of the shell. Caesy is not case sensitive, so 
‘abc’, ‘ABC’, ‘AbC’ and ‘abC’ are all equivalent. Inter- 
nally, Caesy treats all symbols as lowercase. Imaginary 
constants, used heavily in control system analysis, are 
input using a real constant with a trailing ‘i’, ‘I’, 
or ‘J’ (e.g., l.Oi, 1.0J). 

Types in Caesy 

Probably the most striking difference between Caesy 
and other Matlab environments is the fact that Caesy 
is a typed language. That is, in Caesy all variables have 
type (e.g., integer, real, string) whereas in Matlab all 
variables typically have no type (i.e., all variables are 
the same type, Matrix). The addition of types to a 
language adds possibilities for making more powerful 
tools, but may place a burden on the user for declaring 
types. 

In Caesy, we use types but put minimal requirements 
on users to declare variable types. The only place one is 
strictly required to declare variable types is when they 
appear as formal arguments in function and procedure 
declarations. Otherwise, the type of a new variable 
(implied by an assignment statement) can be synthe- 
sized from the type of the right hand side expression in 
the assignment. For example, in the statement 

caesy> abc := 3 + 4; 

the right hand side has type integer so if abc was not 
previously declared, Caesy automatically declares the 
variable abc and gives it type integer. 

Explicit type conversion in Caesy is performed, by 
convention, by declaring a function with the type name. 
For example, a function to explicitly convert integers 
to real is declared as 

function real(i: integer) return x: real; 
and then used, for example, as 
x := sqrt (real(2) ) ; 

Statements 

Caesy supports many of the statements and control 
structures found in Ada with the multiple assignment 
form taken from Matlab. 

Assignment Statements 

Assignment statements take the normal form as well 
as the multiple assignment form familiar to Matlab 
users. Here are examples of the two forms: 

caesy> abc ;= 3 + 4; 

caesy> { x, y, z > := fctn(abc, 3.0); 

One of the statement terminators or *?’ is required 
in Caesy. Just hitting the return key will not do. The 
‘?’ implies that the result of the assignment should be 
displayed to the user: 


caesy> abc := 3 + 4? 
abc ; = 7 ; 

If an expression ex pr appears alone on the command 
line, an implied assignment of the form 

‘_ans ^type-name := ex pr?' 

is interpreted. For example: 

caesy> 3+4; 

_ans_integer := 7; 

Flow Control Statements 

Control constructs allow the programmer to do 
branching and looping. In Caesy, the if-then branching 
is similar to many languages. An example is 

if i < 0 then 
j := 1; 

elsif i = 0 then 
j := 0; 
else 

j := 1; 

end if ; 

Looping in Caesy is reasonably flexible. There are for- 
loops, while-loops, etc. Some examples are 

for i in 1..3 loop j := 3* j ; end loop; 
while j < 30 loop j := 3+ j ; end loop; 
loop j := 3* j ; exit when j >=30; end loop; 

User-Defined Subprograms 
Subprograms in Caesy take the form of functions and 
procedures. (Matlab has no procedures). The following 
is an example of a user-defined function definition. 

function myabs(i: integer) return j: integer is 
begin 

if i < 0 then j:* -i; else j:* i; end if; 
return ; 
end nyabs; 

An example of a procedure definition is the following: 

procedure swap(x, y: in out real) is 
temp: real; — declaration optional! 
begin 

temp :=x; x := y; y := temp; 
return; 
end swap; 

Overloading Functions 

One important feature needed in design interfaces 
for handling complexity is overloading functions and 
operators. Overloading allows a user to write functions 
of the same name and purpose to operate on different 
object types. For example, we could define a function 
myabs similar to the one above, hut which operates on 
reals. 
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function myabs(x: real) return y: real is 
begin 

if x < 0 then y :* -x; else y :* x; end if; 
return; 
end myabs ; 

Function overloading is very handy in control system 
analysis. For example, one could use the expression 
freq(G) to produce a frequency response plot whether 
G represents a transfer function in state-space form, 
rational form, or anything else. In each case, a different 
function would be called depending on the argument 
type. 

Caesy does not overload the return argument(s) of 
a function as Ada does. This is difficult to imple- 
ment, would prohibit the ability to synthesize expres- 
sion types and hence would require users to type- 
declare all variables (see above). 

Overloading Operators 

Caesy also provides the capability to overload most 
operators. Operator overloading allows users to over- 
load operations such as £ A+B’ where A and B have user- 
defined types. For example, given two transfer func- 
tions G1 and G2 in state-space form or rational form, 
we could overload the operator ‘ + ’ to compute a trans- 
fer function in state space form for the parallel con- 
nection of two transfer functions. The declarations of 
these functions in Caesy would look like 

function "+ M (G1: st_sp; G2 : st_sp) 
return G: st_sp; 
function H + M (Gl: rat; G2: rat) 
return G: st_sp; 

function *' (G 1 : st.sp; G2 : rat) 
return G: st_sp; 

function H + M (G1: rat; G2: st_sp) 
return G: st_sp; 

If Gl and G2 were two transfer functions in either state 
space (st_sp) form or rational (rat) form, the expres- 
sion G1+G2 would produce a state space representation 
of the transfer function. An alternative to the expres- 
sion G1+G2 is the explicit function call ,, + M (Gl ,G2). 

Default Input Arguments 

Users of Matlab are accustomed to a variable number 
of input arguments. In the case where input arguments 
are not given, default arguments must be supplied in 
the subprogram declaration. In Caesy, a user need not 
specify all input arguments if default arguments are 
given in the subprogram declaration. For example, the 
following function declaration fragment contains a de- 
fault input argument: 

function abc(x: real; y: real := ydef) 

The function could be referenced, for example, as 
abc(xl, yi) or as abc(xl). In the latter case, the 
value of the global variable ydef would be used for the 


second argument. In Matlab, unspecified inputs are 
handled within the function body. In Caesy, the user 
can change the default input variable, and hence the 
behavior of the function, at any time. 

Variable Number of Output Arguments 

Caesy supports definition of functions with more 
than one output argument. In this case, if the function 
is used in a simple expression, only the first argument 
is referenced. In the case of a multiple-return assign- 
ment (see above), one or more return arguments may 
be referenced. In the function body, usage of return 
arguments can be determined via the ‘argused' opera- 
tor. For example, consider the following function which 
echoes its input arguments: 

function echo(il: integer; i2: integer) 

return { j 1 : integer; j2: integer } is 
begin 

jl : = ii; 

if argused j2 then j2 i2; end if; 
return; 
end echo ; 

Procedures 

In Caesy, users may define functions and procedures. 
Caesy was provided with the ability to define proce- 
dures for reasons of efficiency. Procedures allow one 
to modify variables without creating a duplicate tem- 
porary variable. For example, suppose one wanted to 
write a function to perform a rank-one change on a 
matrix. This could be done with a function call of the 
form 

A = rankfctn(A, x); 
or with the procedure 
rankproc(A, x) ; 

The difference here is that the function rankfctn will 
create a copy of the matrix A to modify and return, 
and then A will be replaced with this matrix. The pro- 
cedure will never create the copy of the matrix A. If 
the matrix happened to be large, the execution speed 
between the functional form and procedural form could 
be quite noticeable. 

Packages 

Several Matlab- type packages use the convention of 
collecting related script files together to form “tool- 
boxes.” Caesy formalizes this convention by using the 
Ada “package” construct. In Caesy, type definitions, 
functions, procedures and global variables can be col- 
lected together in packages. In Matlab, there is no 
clean way to distinguish between two different func- 
tions of the same name in two different toolboxes. This 
can lead to severe problems and requires that users and 
toolbox developers take care to avoid the “name-clash” 
problem. In Caesy, this problem can be avoided easily. 
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If a user wishes to explicitly refer to an object in one 
package when there may be a conflict, the user affixes 
the object name to the specific package name (a con- 
cept borrowed from Ada). For example, to explicitly 
reference the function xyz from the package mypckg, 
one would use the construct mypckg . xyz (args ) . 

Matrix Expressions 

The ability to create and manipulate matrices is of 
fundamental importance in control system engineering. 
In Caesy, matrix expressions, those expressions used for 
constructing matrices from their parts, are supported 
in a unique way. An example of a matrix expression is 
the following: 

A := [ l.i, 1.2; 2.1, 2.2] ; 

This is a two-by-two real matrix. In Caesy, the type 
for this matrix is ‘ReGeMat 1 , for Real General Matrix. 
Complex matrices have type c CoGeMat\ 

C := [ 1.0 + O.li, 1.2; 2. li, 2.2]; 

In the future, we plan to have special support for sym- 
metric and Hermitian matrices, sparse matrices, etc. In 
Caesy, matrices are constructed using overloaded oper- 
ators. The above expression for defining ‘A’ gets inter- 
nally translated, in essence, to the following sequence 
of calls: 

TOvl := M [ M (1 . 1) ; 

T0v2 "/’(TOvl, 1.2); 

T0v3 M ;"(T0v2, 2.1); 

T0v4 := M , M (T0v3, 2.2); 

A := ”] M (T0v4, 2.2); 

The variables starting with T are temporary variables 
created by Caesy. When Caesy sees the first ‘1.1’ 
it looks for the function ”[” which takes a real ar- 
gument. (There are also ”[” functions defined which 
take an integer or a complex value as the first argu- 
ment.) In the Caesy MATMATH package, this function 
is defined, and returns a special type, regematlist, 
for matrix expressions. When the token T.2 1 is seen, 
Caesy looks for a function ” / which takes arguments 
of type regematlist and real. The process continues 
until the function ”]” taking a regematlist and re- 
turning a regemat is called. By implementing matrix 
expressions with overloaded operators, we have made 
the matrix expression construct potentially usable in 
very creative ways. 

Support of Constructors and Destructors 

In Caesy, if a procedure of the form 

procedure constructor (vble: in out Type) 

exists for some variable of type ObjType, then that pro- 
cedure will be called automatically when the variable 
comes into scope. Additionally, if a procedure of the 
form 


procedure destructor(vble : in out ObjType) 

exists for some variable of type ObjType, then that pro- 
cedure will be called automatically when the variable 
comes into scope. 

Implementation 

Caesy is written primarily in C. The internal struc- 
ture is shown in Figure 1. It includes a supervisor to 
prompt for input, a parser, written in YACC, a byte- 
code compiler, a byte-code interpreter, a C code com- 
piler, a context (variable, types, etc.) handling module 
(made of CX/Sys-Ct.xt blocks in the figure), an input 
output interface, and more. The parser outputs LTU 
(language transfer utility) codes which can be compiled 
into byte-codes or C code. 

Work in Progress 

In this section we discuss features which are par- 
tially implemented or are in the process of being im- 
plemented. 

User Defined Structured Data Types 
Caesy will have the capability for the user to define 
structured (i.e.,Tecord) data types. This is an essential 
feature needed in the reduction of complexity. 

Exception Handling 

Currently, Caesy has some support of except ion han- 
dling. Internally, every Caesy function returns an ex- 
ception code to its caller. If the function executes 
normally, it returns the exception code H0_ERR0R. On 
the other hand if some anomaly occurs, a different ex- 
ception will be raised. For example, if one tries to 
take the square root of a negative (real) number, a 
NUMERIC_ERR0R exception will be raised. Caesy will 
trap machine exceptions. If a divide-by-zero occurs, a 
NUMERIC_ERR0R will be raised. The exception will be 
passed until it gets to the supervisor level. For exam- 
pie, 

caesy> a := sqrt(-9.0); 

Supervisor caught NUMERIC.ERROR exception. 
caesy> 

This capability will be extended to allow exceptions to 
be handled in user-defined functions. 

Data Files 

Users often have the desire to store and retrieve data. 
In Caesy, data files will have special binary formats and 
store data in a machine-independent form. The data 
files will support user-defined types and hence, must 
be quite flexible. The stored data files will make use of 
the Sun XDR (external data representation) [3]. 
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Figure 1: Implementation of Caesy 


Code Generation 

Caesy allows users to generate C code from their sub- 
program scripts. For example, for the following code 
segment, Caesy will produce the C code shown in Fig- 
ure 2. 

use matmath; 

function test (A: regemat; B: regemat) 
return C: regemat is 
begin 

for i in 1 . . 10 loop 
C := A*B - B*A ; 
end loop; 

C := [ C ; [ A, B ] ]; 
return; 
end test; 

The C coding capability also makes the prospect of 
developing stand-alone programs attractive. An often- 
used application could be converted to C-code and com- 
piled to run as a specialized program, making it more 
efficient. This feature also has the potential of allow- 
ing users to change a routine to make it as efficient as 
possible. In all, this is a very desirable feature. 

Remote Computing 

There is currently work in progress by another team 
at JPL; the team is implementing a remote computing 
capability in Caesy. This is being developed using Sun 
RPC calls [3]. 

Matrix Computations 

Many of the matrix computations in Caesy are per- 
formed using BLAS and LAPACK [4]. These are state- 
of-the-art FORTRAN libraries in computing solutions to 
linear equations and computing eigenvalue decomposi- 
tions. In fact, Caesy could be viewed as a user-friendly 
interface to LAPACK and, with Caesy 's C code com- 
piler, Caesy may be an attractive way to develop code 
based on both these routines. 


Future Work 

In this section we discuss features which are under 
consideration for future implementations. One object, 
of the Caesy project is to determine what features in an 
interactive shell are needed for handling large, complex 
problems. 

Function and Operator “Tagging” 

The semantics of creating matrices using the ’[’, V, 
and ’]’ operators have a drawback. It may be nice 
to be able to use the construct to input, for example, 
sparse matrices. A sparse matrix could be input as 

Asp := [ 1,1, 1.1; 2,1,2. 1 ] ; 

where 1 , 1 , 1.1 indicates the element in row 1, col- 
umn 1, is 1 . 1 and so on. This type of flexibility cannot 
be supported by the current semantics of the language. 
There is no way that Caesy knows that a sparse ma- 
trix definition is intended. One work-around could be 
to “tag” the first value with an explicit type cast: 

Asp := [ spmatelt(l , 1 , 1 . 1) ; 2,1,2. 1 ]; 

Here we have a special “sparse matrix element” type 
that tags the first element to allow Caesy to find the 
function which takes a sparse matrix element type. 

Another work-around, which would provide more 
flexibility to the Caesy language overall, would be to 
add tagged functions and operators to Caesy. In this 
option, function and operators could have tags to in- 
dicate that special operators should be used. The tag 
would take the special form function; tag in both its 
declaration and use. The tagging approach would al- 
low the user to use the following to generate a sparse 
matrix (of type ReSpMat): 

Asp := [ : sp 1 1, 1.1; 2, 1, 2.1 ] ; 

The declaration for the operator [ may have been 
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#include "kc.h" 


kcXcode 
_Ul_ltest ( 

MATMATH_regemat* a, 

MATMATH_regemat* b, 

MATMATH_regemat* c) 

{ 

MATMATH_regemat TlvO; 

MATMATH.regemlist* Tlvl; 

MATMATH_regemlist Tlv2; 

MATMATH_regemat Tiv3; 

MATMATH_regemlist* Tlv4; 

MATMATH_r eg einl is t Tlv5; 

{ 

int i ; 

MATMATH_regemat T2v0; 

MATMATH_regemat T2vl ; 

MATMATH.regemat T2v2 ; 

{ 

i = l; 
for (; ;) 

if (i>10) break; 

MATMATH_lMUL(a, b, &T2vl) ; 
MATMATH_lMUL(b, a, &T2v2) ; 
KATMATH.iSUB(ftT2vl, &T2v2, &T2vO) ; 
MATMATH_lASSN(c , &T2vO) ; 

> 

i = i + 1 ; 

> 

> 

MATHATH_ldestructor(*T2v2) ; 
MATMATH_ldestructor(ftT2vl ) ; 
MATMATH_ldestructor(ftT2vO) ; 

> 

MATMATH_2MST (c , ftTlv2); 

MATMATH_2MST(a, *Tlv5); 

MATMATH_2MEL(&T1 v5 , b, &Tlv4) ; 
MATMATH_lMND(Tlv4, ATlv3); 

MATMATH_2MR0 (£Ti v2 , ftTlv3, ATlvl); 
MATMATH_lMND(Tlvl , ftTlvO); 

MATMATH_ 1 ASSN ( c , &TlvO) ; 

MATMATH_3destructor (4T1 v5) ; 
MATMATH_ldestructor (ftTlv3) ; 
MATMATH_3destructor(ftTlv2) ; 
MATMATH_ldestructor (&TlvO) ; 

return (kc_X_NO_ERRDR) ; 


function M [*' :sp(i: integer) 
return list: respmatlist ; 

Parallel Computation 

Since Caesy has been developed primarily to explore 
ways in which to increase computational throughput 
for control design tools, it is only natural to pursue the 
possibilities of parallel computation. Several worksta- 
tions and hardware co-processor boards with multiple 
processors are currently available on the market. IIow 
to best support these multiprocessor environments will 
most likely depend on which machine and operating 
system we run under. Currently, Mach derivatives and 
Solaris have support for multi-threaded programming 
at the C language level. 

Conclusion 

In this report we have provided a glimpse of a new 
software environment , Caesy, which will he used for the 
development of algorithms and software for Ihe design 
of large, complex control systems. The tool provides a 
“next-generation” approach to control system design 
by taking advantage of some concepts from object- 
oriented programming languages. The tool should 
prove to provide a means for easily handling large, com- 
plex design problems. It is also being used as a “com- 
putational engine” in a tool for integrated (conceptual) 
design of advanced optical systems. 
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